Coding Conventions

Production Code

• Every method must be checked by at least one JUnit Test.

• We program defensively:

  ‘defensive programming’ describes a way programming giving users of an API detailed error messages when they use it wrong, for instance (but not limited to) by checking input arguments. This might lead to less bugs. For example, a method may return useable, but false values. Defensive programming would check the input arguments and throw an exception and prevent the programmer from continuing with false values.

• Defensive programming is verfied with JUnit test cases.
• Getters exposing internal collections should return copy-on-write versions to prevent modification of internals and providing easy use of the returned collection. This behaviour needs to be documented.
• It is highly recommended to use the Apache Commons wherever applicable. Especially parameter checks, equals(Object) and hashCode() should be implemented using them (see lang3.Validate and lang3.builder.*).

Prototypes

• Prototypes don’t need Unit Tests
• Prototypes don’t need to be documented as well as the normal source code.

Javadoc Style Convention

All parts of the Javadoc are written as full sentences, including that they begin with a capital letter and end with a full stop.

Naming Convention

• Class names are written in UpperCamelCase as defined by Google(archived) and have a minimum length of 3 characters.
• Method names are written in lowerCamelCase as defined by Google(archived) and have a minimum length of 3 characters.
• Attributes are written in lowerCamelCase as defined by Google(archived) and have a minimum length of 3 characters.
• Package names are written in lowercase and have a minimum length of 2 characters per part.

Use of Acronyms

• Only acronyms used in the SRS are permitted.
• Acronyms are treated as normal words and are spelled as specified in Naming Convention. They are not capitalised.

Tags

• @param and @returns tags have to state their value ranges if they refer to primitive data types as well as stating whether they can be null and the meaning of them being null if they refer to object data types.
• Unnecessarily stating the package when using {@link} or {@see} tags is forbidden.